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I.  INTRODUCTION 


A.  PURPOSE 

The  current  environment  of  the  Naval  shipyards  is  characterized  by  an  ever 
decreasing  workload  and  larger  reductions  in  budgets.  This  situation  calls  for  ever 
increasing  and  more  uniform  management  control.  The  high  sensitivity  of  management 
and  schedule  control  over  the  overhaul  duration  and  cost  has  forced  the  conversion 
from  the  shipyard  MIS  based  installed  PERT  CPM  scheduling  system  to  the 
Fundamental  Automated  Scheduling  System  (PASS)  which  can  support  real  time 
network  analysis  and  decision  making.  This  real  time  scheduling  system  was  aimed  at 
allowing  the  shipyards  to  better  manage  manhours  and  material  costs  which  are  critical 
factors  associated  with  cost  overruns  and  the  meeting  of  prescribed  overhaul 
completion  dates.  With  cost  and  time  as  key  variables,  the  decision  was  announced  on 
11  July  1984  that  competitive  procurement  was  underway  for  Naval  shipyards  to 
procure  an  "off-the-shelf  system  in  lieu  of  an  outside  "design  and  build"  contract. 
(Ref.  1|  The  focus  of  this  research  is  to  examine  the  Naval  Shipyard  scheduling  system, 
scheduling  information  flow  and  organization;  then  to  review  the  implementation 
strategy  used  at  Puget  Sound  Naval  Shipyard  as  compared  to  the  strategy  for 
implementing  the  new  scheduling  system  (within  the  boundaries)  of  the  management 
information  system  existing  at  other  shipyards. 

B.  SCOPE 

This  research  addresses  the  problems  associated  with  integrating  the 
Fundamental  Automated  Scheduling  System  (PASS),  a  PERT  CPM  based  overhaul 
scheduling  device,  into  U.S.  Naval  Shipyards.  Due  to  the  uniformity  of  the  shipyards, 
the  recommendations  and  conclusions  are  applicable  to  all  locations.  In  this  light,  all 
activities  were  consulted  in  order  to  benefit  from  the  planning  and  experience,  to  date, 
by  each  activity.  Implementation  questions  were  not  limited  to  physical  or  hardware 
requirements  uses  but  also  covered  the  areas  of  management  acceptance,  utilization  of 
existing  shipyard  systems,  graphics  utilization,  dependability,  and  worker  acceptance 
and  understanding.  The  mission,  organization,  duties,  and  constraints  of  the  Naval 
shipyards  are  first  described  so  that  the  reader  has  a  better  understanding  of  the  overall 


scenario. 


I'his  section  is  devoted  to  the  background  and  profile  of  the  Puget  Sound  Naval 
Shipyard,  fhe  general  concept  of  Automated  Scheduling  is  developed  so  that  the 
reader  will  have  the  necessary  understanding  to  relate  the  use  of  PASS  to  solve  the 
shipyard  scheduling  problems.  I  he  discussion  then  shifts  to  the  implementation  of  the 
system  in  the  shipyards  and  how  each  shipyard  is  utilizing  its  version  of  PASS.  The 
various  versions  are  analyzed  and  alternatives  are  presented,  resulting  in  a  summary  of 
recommended  actions  and  suggestions  for  further  research. 

C.  RESEARCH  TECHNIQUE 

Initially,  a  case  study  methodology  was  performed.  Information  from 
managerial,  staff,  and  production  personnel  who  manage  or  use  FASS  resources  within 
the  operations  environment  was  collected  during  interviews.  Background  data  on  the 
organization  of  FASS  resources  at  all  activities  vas  also  gathered.  On  site  data 
gathering  and  interviews  were  conducted  during  one  ten  day,  two  three  day.  and  two 
one  day  visits  to  Puget  Sound  Naval  Shipyard  by  LCDR  Cole;  one  two  day  visit  to 
Long  Beach  Naval  Shipyard  by  LCDR  MacDonald;  one  two  day  visit  to  Charleston 
Naval  Shipyard  and  four  day  attendance  of  the  FASS  Users  Group  conference  at 
Portsmouth  Naval  Shipyard  by  LCDR  Cole.  Background  reading  was  conducted  to 
better  understand  the  shipyard  scenario  as  well  as  look  at  commercial  and  industrial 
approaches  to  implementing  a  computerized  scheduling  system.  The  background 
reading  consisted  of  shipyard  organization  manuals,  shipyard  MIS  manuals,  system 
requirements  and  specifications  for  FASS  and  historical  information  concerning  the 
conception  of  the  system  procurement. 
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II.  PROFILE  OF  A  NAVAL  SHIPY  ARD 


A.  GENERAL  OVERVIEW 

To  help  the  reader  understand  the  complexity  of' a  Naval  Shipyard,  especially  one 

doing  both  conventional  and  Nuclear  work,  this  chapter  is  devoted  to  a  brief  look  at 

the  general  duties,  organization,  and  functions  of  the  shipyard. 

The  Naval  Shipyard  complex  consists  of  eight  member  yards  located  in 

Bremerton,  WA  (Puget  Sound),  Vallejo,  CA  (Mare  Island).  Long  Beach,  CA,  Pear! 

Harbor,  HI.  Charleston,  SC,  Norfolk,  VA,  Philadelphia,  PA.  and  Portsmouth.  NIL 

The  official  mission  assigned  to  the  Naval  Shipyard  by  the  Secretary  of  the  Navy  is: 

To  provide  losistics  support  for  assigned  ships  and  service  craft:  to  perform 
authorized  work  in.  connection  with  construction,  conversion,  overhaul,  repair, 
alteration,  dry-docking,  and  outfiting  of  ships  and  craft,  as  assigned;  to  perform 
manufacturing,  research,  development  and  test  work,  as  assigned:  to  provide 
services  and  'material  to  other  activities  and  units,  as  directed  bv  competent 
authority.  [Ret.  2] 

In  order  to  carry  out  their  functions,  each  shipyard  maintains  an  industrial  plant 
with  extensive  shop  facilities:  shipfitting,  welding,  shcetmetal.  pipe,  inside  and  outside 
machine,  paint,  service  and  tool,  electrical  and  electronics,  and  rigging.  Each  shipyard 
also  maintains  a  full  range  of  personnel  with  engineering,  design  and  shop  skills.  With 
the  exception  of  nuclear  work,  shipyards  perform  basically  the  same  functions; 
therefore,  the  Puget  Sound  Naval  Shipyard  will  be  used  throughout  this  text  as  an 
example. 


B.  ORGANIZATION 

Pictured  in  Figure  2.1  is  the  non-nuclear  organization  chart  for  the  Production 
Department  at  Puget  Sound.  [Ref.  3j  The  Production  Officer  has  direct  access  to  the 
Shipyard  Commander  for  all  areas  of  production.  The  Repair  Officer  reports  directly 
to  the  Production  Officer  and  deals  with  production  priorities  and  resource  utilization. 
In  order  to  discharge  these  duties  the  Repair  Officer  is  supported  by  an  Assistant 
Repair  Officer,  Docking  Officer  and  a  Production  Control  Branch  Head.  To  keep 
track  of  the  status  of  approximately  live  to  ten  ships  on  a  daily  basis  the  Repair  Officer 
assigns  Ships  Superintendents  to  each  ship. 
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The  Production  Control  Branch  will  be  examined  in  detail  as  this  department  is 
responsible  for  the  control  of  PASS.  In  support  of  the  shipyard  Production  Officer, 
the  Production  Control  Branch  is  responsible  for: 

*  "Providing  workload,  workforce,  and  scheduling  data  required  in  the 
management  of  the  Production  Department  and  for  inter-department 
information  and  coordination. 

*  Serving  as  principal  assistant  to  the  Repair  Officer  on  matters  pertaining  to 
workload  workforce  balance,  scheduling,  production  material  control  and 
master  work  control  systems  for  all  Production  Department  work. 

*  Analvzing  current,  projected  and  long  range  workload  and  workforce,  and 
proposing  changes  required  to  achieve  balance. 

*  Determining  phvsical  progress  of  productive  work  (including  support  svstems 
and  preparatory' work)."  fRet.  4j 

To  meet  the  above  requirements  the  Production  Control  Branch  provides; 
PERT  CPM  schedules  to  control  and  sequence  the  production  effort,  workload 
forecasts  to  manage  employee  resources,  and  project  future  manpower  requirements. 
The  Production  Control  Branch  also  provides  progress  measurement  to  asses  actual 
overhaul  status  for  comparison  to  the  management  plan. 


C.  OVERHAUL  SEQUENCE 

This  section  provides  the  reader  with  a  background  to  understand  a  typical 
shipyard  overhaul  sequence.  The  easiest  way  to  understand  this  process  is  to  use  the 
concept  of  event  management.  The  event  management  system  is  based  on  establishing 
and  monitoring  events.  An  event  is  defined  as  a  specific  accomplishment  at  a  specific 
point  in  time.  The  scheduling  hierarchy  contains  five  interrelated  levels,  each  level 
more  definitive  and  supportive  of  the  upper  tier  schedules.  The  event  hierarchy 
contains  three  levels  of  events  with  appropriate  management  responsibility  and 
visibility  at  each  level.  The  total  event  level  schedule  is  the  third  level  of  the  scheduling 
hierarchy.  Each  key  event  provides  a  discrete,  well  defined  point  in  time  where  the 
status  of  related  jobs  may  be  examined  and  the  progress  evaluated.  Shipyard 
Commanders  or  higher  authority  determines  the  key  events  which  will  determine  the 
actual  status  of  a  ship's  overhaul.  A  typical  overhaul  sequence  with  key  events  listed  is 
provided  in  Figure  2.2.  The  same  key  events  depicted  on  Eigure  2.2  normally  establish 
the  critical  path  for  the  overhaul. 

Although  the  Key  Events  shown  make  the  overhaul  appear  straightforward  with 
only  a  limited  number  of  key  events,  the  reader  must  be  exposed  to  the  complexity  of 


13 


DOCK 


UNDOCK 

STEAMING 

DOCK  TRIALS 

SEA  TRIALS 


Figure  2.2  Typical  Non-Nuclear  Overhaul  Sequence. 

completing  the  work,  leading  to  a  key  event.  Figure  2.3  displays  the  typical  interrelated 
systems  work  phases  leading  to  a  Key  Event.  As  an  example,  the  Engineering  Plant 
Light  Off  Key  Event  represents  approximate  five  hundred  job  orders.  The  engineering 
plant  of  a  destroyer  class  ship  has  four  main  engine  spaces  and  up  to  30  smaller 
auxiliary  spaces.  Each  main  engineering  space  has  15  major  systems  which  contain 
approximately  900  valves  and  components.  Each  valve  will  not  only  require 
maintenance  and  or  rework  during  the  yard  period  but  will  also  require  inspection  and 
testing  prior  to  and  during  light-off.  Now,  add  the  training  required  by  a  new  crew  to 
operate  a  complex  engineering  plant  with  electronic  systems,  multiply  this  by  four,  then 
add  the  auxiliaries  equivalent  and  the  successful  occurrence  of  a  key  event  becomes  a 
mind  boggling  evolution  of  enormous  size  that  defies  the  best  of  management 
techniques  and  systems.  [Ref.  5] 
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Figure  2.3  Tvpical  Interrelated  Work  Phases 
Lea'ding  to  a  Key  Event. 
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D.  THE  OVERHAUL  ASSIGNMENT  PROCESS 

Normally,  a  Naval  Shipyard  does  not  "bid"  for  an  overhaul  contract  in  the  same 
manner  as  a  private  shipyard  does.  Naval  Sea  System  Commands  (NAVSEA)  and  the 
Chief  of  Naval  Operations  assign  workloads  to  individual  shipyards.  Such  variables  as 
construction,  conversion  and  overhaul  schedules,  yard  capabilities,  yard  specialties, 
existing  homeport  policies,  and  total  shipwork  all  play  a  role  in  determining  where  each 
overhaul  is  assigned.  The  individual  shipyards  provide  inputs  but  do  not  control  the 
assignment  process.  This  process  constitutes  a  factor  that  can  greatly  affect  a 
shipyard's  planning  process.  Competitive  policies  and  procedures  are  currently  being 
developed  which  will  force  Naval  Shipyards  to  "bid"  against  private  shipyards  or 
themselves  for  a  portion  or  all  of  their  assigned  work. 

E.  SHIPYARD  MANAGEMENT  CONSTRAINTS 

The  constraints  placed  upon  shipyard  management  are  not  greatly  different  from 
those  placed  on  industry,  however,  they  should  be  briefly  reviewed.  The  four  major 
constraints  are:  available  manpower,  authorized  work,  schedule  adherence,  and 
maximum  allowable  cost.  All  four  constraints  are  interrelated.  With  regard  to 
available  manpower,  the  shipyard  must  employ  sufficient  labor  skills  to  complete  the 
assigned  work.  To  accomplish  this,  forecasted  workloads  are  derived  and  a  suitable 
workforce  is  established.  Unique  from  the  public  sector  shipyard  is  the  fact  that  all 
workers  are  government  employees  which  removes  the  option  of  acquiring  manpower 
on  a  daily  basis  from  a  union  labor  pool.  This  constraint  is  often  costly  when  shipyard 
workload  varies  significantly. 

Estimated  cost  impacts  directly  upon  both  the  authorized  work,  (the  second 
constraint)  and  maximum  cost,  (the  fourth  constraint).  The  estimated  cost  of  work  is 
produced  by  examining  current  labor  and  material  costs.  Given  a  maximum  allowable 
cost  of  an  overhaul,  the  ship's  captain,  type  commander,  and  the  shipyard  develop  a 
priority  work  package  of  required  work  that  fits  within  that  maximum  allowable  cost. 

Schedule  adherence  (the  third  constraint),  is  mandated  from  the  Chief  of  Naval 
Operations  level  (CNO).  The  CNO's  office  controls  total  force  requirements  and 
therefore  limits  the  period  of  time  that  a  vessel  can  be  taken  "off  the  line." 

The  four  constraints  have  been  described  briefly  to  give  the  reader  an  overview  of 
a  few  of  the  factors  that  dominate  shipyard  management.  These  elements  combine  to 
severely  tax  the  efforts  of  the  Production  and  Repair  Departments  to  develop  and 
maintain  a  ship's  overhaul  schedule. 


F.  SCHEDULE  ADHERENCE 

The  bottom  line  of  any  repair  activity  is  their  ability  to  accomplish  proper  repairs 
within  a  limited  time  frame  and  budget.  More  specifically,  the  shipyard  Repair 
Officer's  problem  is:  "When  several  vessels  are  in  overhaul,  how  can  a  master  schedule 
be  maintained  while  taking  into  consideration  individual  unit  schedules,  fixed  overhaul 
workload,  manpower,  and  cost  constraints?"  Other  factors  (i.e.,  political  and 
operational  pressures)  often  occur  thereby  increaseing  the  outside  contracting 
requirements  causing  a  reduction  in  the  budget  and  time  allotted  for  the  overhaul. 
This  situation  requires  the  shipyard  management  to  frequently  answer  many  "What-Ifi" 
questions  in  the  planning  and  scheduling  of  their  resources.  The  problem  is  very 
complex  and  no  specific  algorithm  can  be  used  for  a  solution. 


III.  AUTOMATED  SCHEDULING  BACKGROUND 


A.  INTRODUCTION  TO  AUTOMATED  SCHEDULING 

Automated  scheduling  is  intended  to  be  used  to  manage  individual  projects  in 
conjunction  with  aggregate  planning  techniques  for  inter-project  analysis.  It  is  a 
powerful  tool  for  scheduling  project  activities  and  for  allocating  scarce  resources 
among  project  activities.  It  can  also  do  risk  analysis  of  project  budgets  and  due  dates. 
However,  in  the  management  of  a  project-oriented  production  system,  such  as  the 
Naval  Shipyards,  major  decisions  must  be  made  involving  aggregate  level  planning 
issues.  These  decisions  include  the  planned  allocations  of  available  resource  time 
among  projects  and  establishment  of  major  milestone  target  dates  for  each  project. 
Due  to  the  extensive  number  of  automated  scheduling  packages  in  use,  only  one  such 
package  will  be  covered  here. 

Automated  scheduling  requires  as  input  data  the  allocations  of  resources  to  a 
project  and  its  target  milestone  dates.  Resource  allocations  to  a  project  are  treated  as 
inviolable  capacities  for  the  project  on  the  grounds  that  exceeding  such  allocations 
would  affect  other  projects.  The  scheduling  algorithms  used  in  an  automated 
scheduling  package  derive  schedules  meeting  the  target  milestone  dates  (if  feasible) 
without  exceeding  the  allocated  resource  levels. 

An  automated  scheduling  package  may  be  used  to  perform  two  different  types  of 
analysis  which  are  termed  "deterministic"  and  "probabilistic".  [Ref.  6]  In  deterministic 
analysis  a  project  schedule  is  derived  assuming  the  work  requirements  for  the  activities 
of  the  project  are  known.  In  addition  to  the  optimal  schedule,  resource  load  profiles 
corresponding  to  this  schedule  are  provided  as  output.  In  probabilistic  analysis, 
scheduling  of  the  project  is  simulated  many  times  with  activity  work  requirements 
randomized  according  to  probability  distributions.  The  user  must  specify  distributions 
defining  probabilities  of  unplanned  rework  activities.  Also,  the  software  will 
incorporate  uniform  distributions  which  randomize  the  work  content  of  the  schedule 
over  a  set  range  (80-120%)  of  given  estimates.  Shipyards  may  evolve  to  probabilistic 
analysis  when  expertise  is  developed  in  the  utilization  of  deterministic  analysis. 

Automated  scheduling  may  provide  confidence  curves  for  the  realization  date  of 
each  milestone  and  confidence  curves  for  the  total  hours  required  of  each  resource. 


Resource  load  profiles  reflecting  a  user-specified  confidence  level  may  also  be  obtained. 
Reviewing  the  results  of  such  work,  the  user  can  assess  the  risks  that  trial  project 
milestones  and  resource  budgets  cannot  be  met. 


B.  SYSTEM  DESCRIPTION 

Simulated  scheduling  is  a  comprehensive  software  package  for  project  scheduling 
and  analysis  developed  at  the  Operations  Research  Center  of  the  University  of 
California  at  Berkely.  [Ref.  6]  It  is  designed  for  use  in  project-oriented  production 
systems  which  have  inflexible  resource  capacities  limiting  the  execution  of  multiple 
projects  with  uncertain  work  requirements.  Both  tabular  and  graphical  output  for 
project  scheduled  and  risk  analysis  may  be  provided.  This  software  is  the  result  of 
research  concerning  the  development  of  mathematical  models  and  techniques  for 
production  management  sponsored  by  the  Office  of  Naval  Research  and  the  Puget 
Sound  Naval  Shipyard. 

The  simulation  scheduling  package  utilizes  the  VM  SP  operating  system  to 
compile  CMS  Fortran  interactive  commands  and  batch  processing  code.  With  some 
appropriate  modifications,  the  Fortran  code  could  be  adapted  to  run  on  other  systems. 

1 .  Summary  of  Data  Requirements 

The  data  requirements  for  simulation  scheduling  are  summarized  below.  Some 
of  the  data  items  are  novel  compared  to  other  project  scheduling  software.  For  this 
reason,  a  brief  discussion  of  the  mathematical  models  of  production  will  be  provided 
following  the  summary  of  data  requirements. 

*  "CPM  ACTIVITY  NETWORK  -  An  activitv-on-arc  network  of  all  planned 
activities  is  specified.  The  "normal"  duration  for  each  activity  is  specified. 

*  RESOURCE  HOURS  --  For  each  activity,  estimated  total  hours  of  each 
resource  to  be  applied  are  specified.  These  resources  are  identified  bv  shop' 
number.  Subcategories  are  designated  bv  "work  center"  number.  Activities 
whose  resource  utilization  levels  "are  not  adjustable  are  designated  with  a  Hag 
in  the  "activity-type"  field. 

*  TARGET  PROJECT  COMPLETION  DATE  -  The  target  due  date  for 
completion  of  all  activities  in  the  project. 

*  TARGET  MILESTONE  DATES  --  Target  due  dates  for  anv  other  events 
mav  be  specified.  If  feasible,  schedules  will  be  developed  meeting  the  target 
dates.  Activities  following  such  events  will  not  be  scheduled  to  start  earlier 
than  the  target  date,  unless  all  predecessors  are  complete  and  it  is  necessarv  to 
do  so  in  order  to  meet  other  due  dates. 

'  SHOP  CAPACITIES  -  Time  varving  levels  are  specified  for  each  resource 
allocated  to  the  project.  The  user  must  spccilv  the  hours  dav  of  each  shop 
available  to  the  project  and  an  effective  date  such  levels  apply.  'Multiple  levels 
and  multiple  effective  dates  are  allowed. 

*  FLOW  TRANSFERS  --  Dependent  activities  which  overlap  instead  of  being 
separated  bv  strict  precedence  have  a  flow  transfer  percentage  specified  to 
define  the  lag  in  the  progress  of  the  two  activities. 
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*  REWORK  SLBNETWORKS  --  _  For  probabilistic  analysis,  subnetworks 
describing  potential  rework  are  defined.  Each  rework  subnetwork  consists  of 
alternative  paths  of  rework  activities  which  mav  be  required  following  a 
particular  activity  in  the  CPM  network. 

*  CALENDAR  DATA  —  The  starting  dates  of  the  individual  projects  to  be 
scheduled  simulated  and  a  list  of  nonAvorking  days  is  provided. 

*  REPORTING  DATES  --  A  list  of  dates  for  reporting  shop  and  work  center 
loading  statistics  is  provided. 

*  MISCELLANEOUS  PARAMETERS  —  To  initiate  the  program,  various 
parameters  must  be  specihed,  These  include  the  number  of  simulations  to  be 
performed,  the  number  of  work  davs  simulated,  upper  and  lower  bounds  for 
activity  intensity,  and  the  intensity  assignment  policy."  [Ref.  6] 

2.  Mathematical  Models  of  Production 

Simulation  scheduling  utilizes  the  network  logic  of  the  critical  path  method 
(CPM).  In  order  for  the  scheduling  model  to  more  realistically  simulate  work  in  the 
project-oriented  production  system,  such  as  a  naval  shipyard,  some  of  the  restrictive 
assumptions  of  CPM  had  to  be  relaxed.  For  example,  the  duration  of  many  activities 
must  be  adjustable  according  to  the  amount  of  resources  applied  to  the  activity.  In 
simulation  scheduling,  the  duration  for  each  activity  is  determined  according  to  the 
simulated  application  of  resources  to  the  activity.  Efficient  activity  durations  and 
schedules  are  determined  by  the  efficient  allocation  of  project  resources  among  the 
activities  of  the  project. 

3.  Resource  Utilization 

In  simulation  scheduling  it  is  assumed  that  all  scarce  resources  utilized  by  an 
activity  are  applied  proportionally.  Using  this  assumption,  the  fraction  of  the  total 
requirement  for  a  resource  that  is  applied  to  an  activity  on  a  particular  day  is  the  same 
for  all  resources  utilized  by  the  activity  on  that  day.  This  fraction  is  called  the 
"intensity  of  the  activity"  on  that  particular  day. 

In  CPM,  it  is  assumed  that  activity  intensity  is  constant  from  the  start  to  the 
finish  of  the  project.  The  value  of  this  constant  is  the  reciprocal  of  the  prespecified 
activity  duration.  However,  in  simulation  scheduling,  activity  intensity  is  allowed  to 
vary  between  upper  and  lower  limits  defined  by  the  user.  The  user  defines  a  normal 
duration  for  each  activity  which  corresponds  to  a  normal  intensity.  The  user  also 
defines  upper  and  lower  bounds  on  activity  intensity,  expressed  as  a  percentage  of  the 
normal  intensity.  The  user  may  also  identify  fixed  intensity  activities.  Fixed  intensity 
activities  are  ones  whose  intensity  must  be  held  constant  at  the  level  corresponding  to 
normal  duration.  All  other  activities  are  assumed  to  have  intensities  which  are 
adjustable  between  the  upper  and  lower  percentage  limits. 
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In  simulation  scheduling,  the  user  must  select  one  of  two  alternative  intensity 
assignment  policies  known  as  "upgrading  only"  and  "upgrading  and  downgrading.  In 
the  "upgrading  only"  policy,  resources  cannot  be  withdrawn  from  an  activity  in 
progress.  On  the  other  hand,  this  is  permitted  under  the  "upgrading  and  downgrading" 
policy.  In  general,  more  efficient  resource  utilization  and  shorter  project  durations  are 
feasible  when  activities  can  be  downgraded  as  well  as  upgraded. 

4.  Activity  Dependencies 

In  CPM.  work  How  is  represented  with  strict  precedence  relationships  between 
activities.  In  simulation  scheduling  a  more  general  work  How  relationship  may  be 
defined  (known  as  a  flow  transfer)  which  may  possibly  reduce  network  size.  An 
example  of  this  relationship  is:  Suppose  three  valves  are  to  be  fabricated  and  then 
installed.  As  fabrication  of  each  valve  is  completed  the  valve  may  be  installed.  CPM 
cannot  accurately  have  one  activity  represent  this  situation.  To  be  completely  accurate 
CPM  would  have  to  use  three  separate  valve  fabrication  activities  and  three  separate 
valve  installation  activities. 

Using  simulation  scheduling  it  is  possible  to  define  one  activity  representing 
the  fabrication  of  three  valves  and  one  activity  representing  the  installation  of  three 
valves  with  a  33.3%  flow  transfer  specified  between  them.  The  33.3%  flow  transfer 
insures  that  the  fabrication  activity  is  always  33.3%  ahead  of  the  installation  activity. 
For  example:  Installation  cannot  start  until  fabrication  is  at  least  33.3%  done  and 
installation  cannot  be  66.6Tb  done  unless  fabrication  is  100.0%  done.  In  this  way,  the 
application  of  resources  to  install  each  valve  will  not  be  simulated  until  after  the 
application  of  resources  to  fabricate  the  valve  has  been  simulated  even  though  only 
two  activities  are  used.  A  100. 0%  How  transfer  value  corresponds  to  the  familiar  strict 
precedence  of  activities.  In  simulation  scheduling  the  default  is  100%  (low  transfer. 

5.  Probabilistic  Networks 

In  CPM  a  given  network  of  activities  is  represented.  In  probabilistic  analysis, 
using  simulated  scheduling,  an  overall  network  is  represented  which  consists  of  the 
given  network  appended  with  randomly  generated  rework  networks.  Many  different 
overall  networks  are  scheduled  in  the  course  of  probabilistic  analysis.  The  user  of 
simulation  scheduling  must  provide  input  data  defining  the  probabilities  and  structure 
of  the  rework  subnetworks  briefly  described  as  follows. 

For  each  rework  subnetwork  the  user  identifies  the  activity  of  the  given 
network  which  immediatly  precedes  the  potential  rework.  For  purposes  of  discussion 


this  activity  will  be  refered  to  as  the  "test  activity."  The  rework  subnetwork  following 
the  test  activity  is  defined  in  terms  of  alternative  paths  of  rework  activities.  Each  path 
is  termed  a  "branch."  The  user  defines  the  probability  that  each  branch  will  arise 
following  the  test  activity.  The  branch  probability  may  sum  to  less  than  1.0  to 
represent  the  case  in  which  there  is  a  chance  that  no  rework  is  required. 

A  graph  of  an  example  rework  subnetwork  is  presented  in  Figure  3.1.  There 
are  three  rework  branches  following  the  test  activity  with  probabilities  0.35,  0.20  and 
0.05  respectively.  For  each  rework  activity  on  each  branch  the  user  specifies  a  normal 
resource  mix  (e.g.,  normal  crew  requirement).  The  user  also  specifies  a  probability 
distribution  for  the  duration  of  the  rework  activity  that  would  be  realized  if  the  normal 
resource  mix  were  applied.  This  distribution  is  expressed  in  discrete  form.  For 
example:  The  duration  distribution  for  rework  activity  might  be  one  day  with 
probability  0.25  and  two  days  with  probability  0.75.  Up  to  five  alternative  durations 
for  each  rework  activity  may  be  specified. 


Figure  3.1  Example  of  Rework  Subnetwork. 


IV.  FASS  BACKGROUND 


A.  WHY  FASS 

The  governing  body  of  Naval  Shipyards  is  the  Naval  Sea  Systems  Command 
(NAVSEA).  In  order  to  supervise  and  standardize  management  practices  within  the 
shipyards.  NAVSEA  issued  NAVSEAINST  4S50.9  on  Februarv  28  1984.  |Ref.  ~]  The 
design  of  this  instruction  was  to  establish  a  minimum  level  of  operational  procedures  in 
the  scheduling  of  non-nuclear  shipyard  work.  The  instruction  requires  each  shipyard  to 
develop  and  maintain  a  hierarchy  of  five  integrated  schedules.  The  descending  levels  of 
scheduling  would  consist  of  more  detail  which  must  be  upward  compatible  and 
supportive  of  all  levels  above  it.  The  five  levels  of  schedules  must  also  be  dynamic  and 
updateable  to  reflect  daily  schedules  up  through  the  Key  Event  schedule.  In  addition 
to  the  scheduling  requirements  NAVSEA  work  load  forecasting  procedures  specifies 
data  requirements  to  assist  in  the  shipyard  management  effort.  A  sample  of  these  are: 


*  "Develop  and  maintain  work  performance  statistics  bv  hull  tvpe  (and  class  if 
appropriate)  and  availability  type  by  direct  labor  shop.' 

*  Base  all  direct  labor  workload  projections  on  data  provided  bv  the  Plannine 
Department.  Where  a  "should  cost  analvsis  report"  has  been  prepared,  modilv 
to  will  cost"  by  using  an  approved  performance  factor. 

*  During  the  availability,  monitor  actual  performance  and  recommend  revisions 
to  the  PEC  as  necessarv  in  order  that  the  "will  cost"  estimate  represents  the 
shipyard's  best  estimate  of  final  expended  direct  labor  mandays. 

*  Prepare  and  maintain  workload  forecasts  for  all  major  direct  labor  shops 
including  support  shops. 

*  Prepare  quarterlv  staffing  recommendations  for  all  major  direct  labor  shops, 
including  support  shops,  for  use  by  the  Management  Engineering  Office  and 
other  departments  in  establishing  departmental  ceiling  and  staffing  plans. 

*  Produce  W'orkload  and  Resource  Reports  and  associated  reports."  [Ref.  8] 
Although  the  above  requirements  were  made  to  improve  shipyard  performance 

the  existing  Automated  Data  Processing  technology  at  the  various  shipyards  could  not 
support  the  requirements.  Shipyard  workloads  are  managed  by  the  Production  Control 
Branch  using  both  automated  and  manual  techniques  including  hand  drawn 
PERT  CPM  charts  and  batch  inputs  to  the  shipyard  management  information  system. 
Numerous  shipyards  had  already  begun  utilizing  commercial  software  packages  to 
assist  in  network  scheduling;  however,  most  were  still  incapable  of  fulfilling  the 
NAVSEA  requirements  even  with  these  packages. 


The  shipyard  MIS  in  the  batch  mode  (for  example)  returns  schedule  information 
in  one  to  three  days.  Manual  network  drawing  may  take  from  two  to  several  weeks. 
With  these  time  constraints  the  information  provided  to  management  was  too  late  and 
of  very  little  use. 

At  this  point  in  time  the  Production  Control  Branch  heads  of  the  shipyards 
collectively  examined  their  inability  to  meet  the  NAVSEA  requirements  and  jointly 
developed  a  solution  to  the  problem.  It  was  determined  that  the  best  alternative  was 
to  obtain  a  current  commercial  "state-of-the-art,  off-the-shelf",  on-line,  user-friendly 
software  package.  Questionnaires  were  distributed  to  all  shipyards  and  appropriate 
studies  were  performed  to  assess  the  actual  requirements.  The  results  of  the 
questionnaires  and  the  studies  were  transformed  into  a  set  of  system  specifications  that 
described  the  objectives  and  potential  benefits  of  PASS  as  follows: 

1.  Objectives 

*  To  shorten  ship  availability  durations  by  providing  the  capability  to  quicklv 
asses  remaining  work  and  define  appropriate  management  action. 

*  To  increase  the  productivity  of  the  Scheduling  Section  by  elimination  of 
manually  prepared  CPM  networks  and  bar  chart's. 

*  To  have  access  to  an  automated,  interactive  project  management  system 
which  can  serve  as  a  tool  in  evaluating  the  impact  of  proposed  scheduling 
and  workload  forecast  changes  and  their  impact  on  one  another. 

*  To  have  the  capability  to  automatically  "forecast  resource  problems"  within 
a  given  schedule  and  identify  the  CFM  activities  involved  which  warrant 
immediate  attention. 

*  To  have  the  ability  to  input  schedule  adherence  and  progress  data  from 
remote  locations. 

*  To  establish  a  more  meaningful  relationship  among  project  schedules,  shop 
manpower  resources,  workload  forecast,  and  progress  data  to  aid  in  the 
analysis  of  performance  and  monitoring  of  schedule-adherence. 

*  To  maintain  a  "Historical  File"  for  future  availabilities." 

2.  Potential  Benefits 

*  To  reduce  overhaul  durations  and  increase  shipyard  productivity. 

*  To  improve  the  quality  of  shipyard  schedules. 

*  To  provide  an  automated  interactive  project  management  svstem  which 
would  serve  as  a  tool  in  evaluating,  the  impact  of  proposed  scheduling  and 
workload  fore<  ast  changes  and  their  impact  on  one  another.  This  on-line 
modeling  capacity  would  allow  shipyard  management  to  select  the  best 
option  in  a  timely' manner. 

*  To  provide  an  automatic  forecast  of  resource  problems  within  a  given 
schedule  and  identification  of  the  activities  warranting  immediate  attention. 
This  would  allow  shop  managers  to  review  manning  problems  far  enough  in 
advance  to  properly  react  resolve  manloading  situations. 

*  An  automated  scheduling  system  would  provide  the  ability  to  input  schedule 
adherence  and  progress  Tata  from  remote  locations. 


*  To  provide  a  more  meaningful  relationship  among  schedule,  workload 
forecast,  and  progress  data  would  allow  the  analysis' of  cost  and  schedule 
performance. 

*  To  provide  for  the  existence  of  an  automated  historical  file  which  would 
reduce  scheduling  effort  bv  allowing  similar  work  package  schedules  to  be  re¬ 
used  with  appropriate  changes.  This  would  also  promote  the  sharing  of 
work  package  schedules'"  among  shipvards  reinforcing  overhaul 
standardization  and  applving  lessons  learned  throughout  the  ships ard 
community."  [Ret.  9] 

B.  SYSTEM  DESCRIPTION 

The  ARTEMIS  software  procured  for  the  shipyards  was  a  user  friendly,  on-line, 
strictly  deterministic,  real  time  management  system  package.  ARTEMIS  has  a 
probabilistic  analysis  network  software  package  which  is  limited  in  application  and 
therefore  has  not  been  procured  by  any  shipyard.  The  ARTEMIS  system  utilizes  a 
Hewlett  Packard  Mini  6000  series  computer  with  various  printers,  plotters,  and 
graphics  terminals.  General  characteristics  of  the  overall  system  include  a  common, 
high  level  command  language  utilized  throughout  the  system.  This  allows  the  first  time 
user  to  be  led  through  the  various  cycles  and  allows  an  advanced  user  to  bypass  the 
initial  instructions  and  proceed  at  their  own  pace.  Self  instruction  facilities  are 
maintained  to  help  new  personnel  using  the  system.  The  established  user  may  develop 
new  data  entry  or  retrieval  formats  and  access  data  within  the  numerous  data  sets 
without  affecting  other  users.  The  system  is  also  capable  of  on  line  and  or  background 
processing.  This  capability  allows  the  user  to  view  the  indicated  process  function  and 
make  corrections  or  changes  as  they  are  displayed. 

A  relational  database  is  utilized  with  the  ability  of  linking  up  to  fifteen  data  sets 
using  dynamically  defined  key  fields.  The  ARTEMIS  system  can  handle  32.000 
activities  per  project,  64  calenders.  32  data  sets  and  256  resources  per  activity.  Data 
input  can  be  accomplished  by  using  a  database,  manual  input,  or  tape  transfer. 

The  approximate  times  involved  in  obtaining  an  output  from  the  system  can  be 
illustrated  by  viewing  two  cases.  The  initial  case  assumes  a  busy  system  with  a  detailed 
PERT  CPM  system  of  several  thousand  activities  such  as  that  required  for  the 
scheduling  of  a  Destroyer  class  availability.  The  time  required  to  receive  an  output 
from  PASS  would  be  approximate  one  and  one  half  hours,  that  is  time  to  retrieve 
data  from  the  database,  analyze  it,  and  have  it  ready  to  plot.  This  output  allows  the 
user  to  see  the  entire  detailed  PERT  CPM  overhaul  schedule.  A  better  example  of  the 
time  savings  of  this  system  is  shown  by  looking  at  a  lower  level  of  detail:  that  is  say. 
the  four  hundred  activity  level  of  the  previously  discussed  Destroyer  class  availability. 


The  time  in  this  ease  is  in  the  vicinity  of  twelve  minutes;  approximatly  two  minutes  to 
retrieve  the  data  from  the  database  and  approximatly  ten  minutes  to  analyze  the  data 
with  the  results  displayed  on  a  graphics  terminal  or  plotted  on  any  of  the  various 
plotters  available. 

The  second  case  is  an  example  of  the  day-to-day  use  of  the  system.  A  supervisor 
utilizing  the  system  at  a  busy  time  can  change  information  concerning  five  specific  jobs 
involved  in  the  four  hundred  activities.  The  five  job  changes  would  require  about  five 
minutes;  two  minutes  for  the  data  retrieval,  one  minute  for  the  data  entry  process  and 
approximatly  two  more  minutes  for  the  analysis.  In  this  instance  PASS  is  providing 
the  much  needed  assistance  to  the  supervisors  in  developing  alternative  solutions 
through  schedule  simulation  thus  illustrating  the  quick  response  time  that  PASS  will 
provide  to  the  waterfront  supervisors. 

The  only  limitation  to  handling  multiple  projects  is  the  system  storage  capacity. 
The  actual  software  and  hardware  makeup  of  each  shipyard's  system  is  individually 
flexible  to  meet  their  present  needs  and  support  that  shipyard  s  demands. 

C.  INITIAL  FASS  UTILIZATION 

While  the  initial  requirement  for  FASS  was  to  enable  the  shipyards  to  comply 
with  the  NAVSEA  directives  on  scheduling  shipyard  management  quickly  understood 
the  magnitude  of  potential  applications  available  with  the  system.  The  ARTEMIS 
package  provided  a  desktop  version  for  project  offices  and  foreman  as  well  as  the 
shipyard  schedulers  and  could  link  a  limited  number  of  its  terminals  to  the  mini  system. 
With  this  link  capability  (the  combination  of  remote  terminals  and  the  desk  top 
program)  the  problem  of  real  time  waterfront  information  interfacing  was  addressed. 
I  he  system  also  provided  the  shipyard  with  the  ability  to  reassign  job  priorities,  order 
of  start  stop  dates,  and  reconstruction  of  the  networks  to  determine  the  affects  of  these 
changes  on  the  critical  path,  resources,  and  other  events.  The  "What-lf  capability  is 
an  immense  improvement  over  the  existing  techniques  used  prior  to  PASS.  The 
resulting  savings  of  the  several  days  of  manual  labor  required  to  develop  a  new 
PERT  CPM  schedule  after  any  major  changes  were  proposed  during  the  overhaul 
process  was  a  quantum  and  very  welcome  jump  in  processing  rates. 
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V.  FASS  IMPLEMENTATION  CONSIDERATIONS 


A.  F ASS/MIS  INTERFACE 

Implementation  of  a  new  subsystem  into  an  existing  mainframe  computer  and 
management  information  system  is  a  complex  and  thought  provoking  exercise  in 
looking  at  both  a  near  term  goal  ti.e.,  implementation  of  a  new  scheduling  application) 
and  the  long  term  goal  of  complete  and  compatible  integration.  All  eight  Navy 
shipyards  have  acquired  the  FASS  system  for  scheduling  overhaul  work  on  Naval 
ships.  This  system  is  a  must  for  management  in  an  era  of  reduced  budgets  and 
decreased  workloads.  The  networking  anahsis  and  What- If'  features  of  FASS  are 
critical  to  sound  management.  The  network  and  management  graphics  provided  by  the 
system  are  necessary  to  maintain  state  of  the  art  information  presentation  to  shipyard 
managers. 

A  prime  implementation  consideration  is  the  ability  to  interface  between  the 
ARTEMIS  60000  minicomputer  (which  runs  FASS)  and  the  shipyard  mainframe 
(Honeywell  6060).  This  arrangement  puts  the  heavy  burden  of  "number  crunching"  on 
the  mainframe  which  has  the  capacity  to  handle  such  a  memory  sink  allowing  the 
FASS  and  ARTEMIS  6000  software  to  assimilate  and  produce  the  charts,  scheduling, 
and  cost  readout  that  schedulers,  foreman  and  managers  must  have  to  judge  work  and 
time  critically.  The  main  strategies  involved  in  implementation  of  the  FASS  System 
involve:  (1)  utilization  of  the  mainframe  data  base  for  FASS  analysis  (2)  providing 
FASS  resultant  schedule  data  to  the  shipyard  mainframe. 

Philadelphia  Naval  Shipyard  advanced  the  idea  of  interfacing  a  minicomputer 
with  the  shipyard  mainframe.  Major  areas  that  required  thorough  coordination  were 
as  follows: 

*  Current  mainframe  capabilities. 

*  Long  term  capabilities  and  capacities  of  the  mainframe. 

*  Effect  of  mini  micro  computers  on  the  data  processing  organization. 

*  Computer  networking. 

The  minicomputer  approach  adopted  by  Philadelphia  was  designated  PASS 
(Production  Automated  Support  System).  A  line  drawing  of  this  arrangement  is  shown 
in  Figure  5.1.  The  advantages  of  such  an  arrangement  are  as  follows: 


I 

* 

1^  *  Data  sharing  ability  between  the  mini  computer  and  the  mainframe. 

'  *  Abilitv  to  share  hardware  and  software  throughout  the  data  processing 

,  department  and  the  shipyard. 

|  *  The  capability  of  combining  data  files  and  standardizing  formats. 

|  *  Fund  usage  optimization  calling  for  less  equipment  and  fewer  communication 

,  lines. 


Figure  5.1  Philadelphia  FASS  Utilization  Network. 


The  FASS  constraints  of  data  entry,  accessibility,  and  memory  capacity  are 
eliminated  by  this  PASS.  Additionally,  this  PASS  allows  the  existing  terminals  in  the 
shipyard  to  obtain  data  from  FASS.  This  system  has  been  fully  implemented  at 
Philadelphia  and  the  following  benefits  are  already  becoming  realized: 


*  Schedule  quality  is  improving. 

*  The  automated  interactive  project  management  system  has  given  the  shipyard 
the  on-line  modeling  capability  for  shipyard  management  “to  review  several 
alternatives  of  schedule  changes  and  to  select  the  best  alternative. 

*  Automatic  forecasting  of  resources  will  allow  managers  to  review  manning 
problems  far  enough  in  advance  to  properly  resolve  those  manloading 
problems. 


28 


The  Long  Beach  Shipyard  approach,  as  shown  in  Figure  5.2,  is  for  connection  of 
the  ARTEMIS  6000  minicomputer  system  with  the  Honeywell  mainframe  via  modem 
for  data  Row.  This  allows  FASS  to  relay  as  well  as  retrieve  information  to  the 
shipyard  MIS  in  real-time  fashion  rather  than  the  previous  batch  process  that  took  up 
to  three  days  to  return  the  appropriate  readout.  The  FASS  software  allows  the 
mainframe  to  do  the  heavy  "number  crunching"  and  retrieves  and  puts  that  information 
into  usable  graphics  for  foreman,  schedulers,  and  managers. 


Figure  5.2  Long  Beach  FASS  Utilization  Network. 

A  constraint  that  originally  developed  at  Long  Beach  has  been  resolved  by  the 
data  processing  department.  In  order  for  FASS  to  be  completely  interactive  with  real¬ 
time  information  there  must  be  a  dedicated  port  into  the  mainframe.  This  constraint  is 
based  on  the  Long  Beach  belief  that  FASS  should  function  as  a  front  end  processor  for 
the  production  scheduling  (PS)  application  of  SYMIS.  Long  Beach  has  resolved  this 
problem  by  having  such  a  port  assigned  to  the  production  and  planning  department 
which  has  the  primary  equipment  and  usage  for  FASS.  A  typical  "Plan  of  Actions  and 
Milestones"  for  interfacing  FASS  to  MIS  is  shown  in  Figure  5.3.  In  addition  to  the 


29 


advantages  cited  for  Philadelphia  Naval  Shipyard,  Long  Beach  Shipyard  is  able  to 
realize  these  potential  benefits: 

*  A  more  direct,  real-time  relationship  among  workload  forecasting,  scheduling 
and  progress  data  allows  the  analysis  of  cost  and  schedule  performance. 

*  Reduction  of  overhaul  durations  and  increased  shipyard  productivity. 

Long  Beach  Shipyard  is  in  the  final  stages  of  full  implementation  of  its  FASS 
system.  Minor  communication  protocol  and  compatibility  bugs  are  being  corrected  for 
the  modem  to  be  the  final  link  between  FASS  and  the  mainframe. 

Puget  Sound  Naval  Shipyard  developed  a  networking  approach  by  designing  a 
Production  Control  Database  that  would  be  the  interface  between  the  SYMIS  and 
FASS.  replacing  the  SYMIS  PS  application.  This  system  network  is  shown  in  Figure 
5.4.  The  obvious  advantage  to  this  arrangement  is  the  fact  that  FASS  is  freed  from 
storage  and  interface  constraints.  This  type  of  setup  allows  the  mainframe  to  continue 
processing  shipyard  weekly  reporting  requirements  while  allowing  FASS  to  create  with 
its  graphics  package  more  limited  and  specialized  distribution  reports.  With  the  proper 
identity  codes,  schedulers  and  leadmen  can  update  the  database  from  any  number  of 

terminals  that  the  shipyard  has.  This  distributed  system  is  a  tremendous  asset  in 

keeping  the  real-time  aspect  of  data  viable  for  FASS.  A  new  wrinkle  with  the 
mainframe  database  and  the  ARTEMIS  6000  minicomputer  is  that  progressmen  and 
schedulers  can  now  conduct  "What-If  studies  on  critical  path  jobs  in  order  to  see 

trends  and  to  optimize  job  scheduling  for  a  more  efficient  use  of  manhours.  A 

summary  of  the  advantages  of  the  Puget  Sound  Shipyard  concept  follows: 

*  A  real-time,  on-line  updating  capability. 

*  Anv  increase  in  the  number  of  shipvard  terminals  allow  more  personnel  to 
utilize  FASS  update  results. 

*  Real  time  work  status  is  available  for  "What-If'  analysis. 

*  The  database  programs  are  able  to  be  utilized  bv  other  Naval  shipvards  due  to 
the  commonalty  of  mainframe  systems. 

*  Any  new  mainframe  purchase  will  not  affect  use  of  the  Production  Control 
database  and  FASS. 

The  FASS  MIS  interface  at  the  shipyards  may  be  off-line  via  magnetic  tape  or 
on-line  via  direct  communication  with  the  mainframe.  The  on-line  method  is  used 
daily  for  progress  and  schedule  updates.  The  off-line  magnetic  tape  interface  is  for 
historical  or  large  bulk  data  transfer  between  the  mainframe  and  FASS.  An  important 
interface  is  between  ARTEMIS  and  the  Production  Control  application.  This  interface 


Figure  5.3  FASS  MIS  Interface  Plan  of  Action  and  Milestones. 
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Figure  5.4  Puget  Sound  FASS  Utilization  Network.. 


is  extremely  important  for  the  overhaul  quality  between  SYMIS  outputs  and  the 
Production  Control  processes.  The  on-line  method  causes  the  ARTEMIS  terminal  to 
act  as  a  remote  job  entry  station. 

On  the  technical  level  implementation  is  all  but  complete  at  all  of  the  Navy- 
shipyards.  The  FASS  User's  Group  (will  be  covered  later)  which  is  comprised  of  the 
personnel  directly  working  with  the  system  in  the  Production  Control  branch  are 
constantly  exchanging  information  that  assists  the  others  in  problems  that  are  common 
to  all.  The  current  ARTEMIS  software  release  (Rel  6.6.1)  is  different  enough  from  the 
6.6.0  release  (which  is  the  application)  that  has  been  implemented  that  these  data 
analysts  share  their  knowledge  for  the  good  of  all. 


B.  ORGANIZATIONAL  considerations 

FASS  is  proving  to  be  an  extremely  powerful  tool  for  scheduling,  graphics,  ;ob 
networking,  and  cost  variance  analysis.  There  is  a  need  for  this  facet  of  shipyard 
production  control  to  have  a  separate  code  in  the  nuclear  and  non-nuclear  organization 
of  the  Navy  shipyards.  The  approved  line  drawing  of  the  current  production  control 


V  y  v 


branch  of  shipyard  organization  is  shown  in  figure  5.5.  A  figure  reflecting  the 
projected  organization  required  to  support  production  control  branch  ADP  functions  is 
shown  in  Figure  5.6. 
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Figure  5.5  Typical  Production  Control  Branch. 
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Figure  5.6  Projected  Production  Control  Branch. 


1  he  reasoning  behind  such  a  structure  is  that  the  sections  of  production  control 
have  the  most  need  for  the  output  of  FASS.  The  above  sections  must  be  intimately 
familiar,  on  a  real  time  basis,  with  the  status  of  approximately  4000  ( non-nuclear)  and 
12oo  i nuclear)  kev  operations  on  a  routine  ship  submarine  overhaul.  The  networks 
that  LASS  can  reproduce  on  screen  or  print  out  at  remote  stations  allows  the 


aforementioned  branches  a  graphic  look  at  actual  progress  on  any  given  job  or  series 
of  jobs  that  lead  to  a  key  event  or  milestone.  Prior  to  the  acquisition  of  IASS  this 
organizational  structure  was  adequate  for  the  needs  of  the  schedulers  and  progressmcn 
because  they  usually  had  to  wait  two-three  days  for  their  work  inputs  to  be  processed 
by  the  SYMIS  (Shipyard  Management  Information  System)  and  returned  in  network 
or  graphic  form  for  analysis.  With  a  real  time,  user-interactive  system  integrated  with 
the  mainframe  the  needs  of  the  Production  Control  Branch  are  satisfied  within  minutes. 
What  has  been  proposed  is  a  new  section  in  the  Production  Control  Branch  that  does 
not  become  directly  involved  with  manpower  estimates  or  manpower  requirements 
(Code  376);  that  does  not  prepare,  issue,  and  maintain  shipyard  schedules  (Code  3”i; 
and  is  not  responsible  for  determining  the  status  of  productive  work  in  terms  of 
physical  progress  (Code  3'S ).  A  completely  new  section  is  needed. 

A  proposal  has  been  forwarded  for  the  formation  of  a  Automated  Systems 
section  (Code  379)  in  the  Production  Control  Branch.  This  new  section  would  be 
responsible  for  the  following: 

*  Administration  of  the  PASS  system. 

*  Liaison  with  shipyard  progressmen  in  improvement  of  graphics  and  reports. 

*  Liaison  with  the  Office  of  Information  Resources  (Code  140.  Shipyard  ADP). 

*  Liaison  with  all  shipyard  department's  automated  systems  personnel. 

*  Liaison  with  all  users  of  FASS  or  Production  Control  products. 

*  Assist  the  work  status,  scheduling  and  progress  sections. 

*  Conduct  all  scheduling  related  development  work. 

The  primary  advantage  of  having  a  section  specifically  assigned  to  developmental 
work  and  improving  graphics  is  that  new  ideas  from  other  sources  as  well  as  the 
personnel  in  Code  379  can  be  synthesized  from  the  ARTEMIS  software.  The 
improved  graphics  can  be  distributed  to  the  other  FASS  systems  in  the  other  shipyards 
and  all  of  the  shipyards  benefit.  Currently.  Naval  Shipyard  Long  Beach  is  involved  in 
this  organizational  change.  There  seems  to  be  a  question  of  just  what  FASS  is  and  to 
whom  it  really  does  belong.  The  main  emphasis  in  the  Production  Control  Section  is 
that  FASS  belongs  to  the  Scheduling  Section  (Code  377).  This  does  not  take  into 
account  the  other  facets  of  FASS  such  as  the  cost  schedule  variances  that  FASS  can 
graphically  portray  or  the  different  forms  that  tie  scheduling  to  manpower,  milestones, 
and  money.  The  somewhat  narrow  strategy  is  that  FASS  should  belong  strictly  to  the 
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Scheduling  Section.  A  more  enlightened  view  is  the  formation  of'  the  separate  section 
to  assimilate  information  from  the  other  shipyards  and  for  one  small  group  of  people 
to  have  the  expertise  of  the  system.  In  all  of  the  shipyards  1-9  people  work,  with 
1  ASS.  The  move  is  to  lure  more  clerical  types  for  the  pure  administrative  burden  that 
accrues  with  such  a  complex  system.  At  Long  Beach  there  are  three  people:  a 
supervisor,  a  technical  operator,  and  a  general  computer  specialist.  This  is  not  really 
enough  to  completely  keep  up  the  daily  processing  of  information  from  the  mainframe 
on  the  three  or  more  ships  that  are  nearly  always  in  overhaul.  It  seems  logical  to  have 
a  separate  section  for  PASS  expertise  and  to  allow  the  other  sections  to  carry  out  their 
primary  responsibilities  in  the  most  efficient  manner  possible.  Portsmouth  Naval 
Shipyard,  Long  Beach  Naval  Shipyard  and  Puget  Sound  Naval  Shipyard  have 
implemented  the  formation  of  the  Code  379  while  there  is  a  nearly  equal  division 
among  the  other  shipyards  in  shifting  to  the  Code  379  organization  or  maintaining  the 
control  of  PASS  in  the  Code  375  office.  Increased  organizational  effectiveness  is  more 
easily  attained  by  specialization  of  functions.  It  is  logical  for  Code  379  to  act  as  the 
primary  PASS  experts  and  let  Code  375  attend  to  the  larger  functions  of  production 
control. 

C.  FASS  USERS  GROUP 

With  eight  shipyards,  as  with  any  eight  organizational  entities  with  the  same 
systems  and  goals,  there  is  the  tendency  to  carry  out  business  eight  different  ways.  The 
eight  Navy  shipyards  operate  under  more  stringent  guidelines  than  any  private  sector 
shipyard.  Because  the  jobs  in  the  shipyard  are  civil  service  there  are  problems  in 
reducing  the  work  force  when  an  overhaul  is  completed.  This  somewhat  constant  work 
force  becomes  extremely  expensive  and  cost  inefficient  in  leaner  times.  The  same 
guidelines  apply  to  the  ADP  section  of  the  shipyard  organization.  The  drive  for 
production  efficiency  is  an  overriding  consideration  in  the  public  sector  shipyards.  To 
ensure  a  semblance  of  commonalty  and  to  keep  effectiveness  at  as  high  a  level  as 
possible,  the  FASS  User's  Group  has  been  organized  comprised  of  the  FASS  user's  and 
implemented  in  all  eight  shipyards  and  SEAADSA.  This  user  group  is  designed  to 
improve  inter-shipyard  communications  in  the  FASS  area  by  the  sharing  of  ideas  and 
products,  by  setting  priorities  for  system  enhancements,  and  to  expedite  the 
development  of  FASS  to  current  state-of-the-art  technology.  The  avowed  purpose  of 
this  group  is  to  improve  shipyard  operations,  reduce  overhaul  and  maintenance  costs. 


and  finally  to  reduce  the  durations  of  regular  overhauls.  The  user  s  group 
accomplishes  this  lofty  aspiration  by  the  following  means: 

*  Establish  and  maintain  a  minimum  level  of  commonalty  in  the  areas  of 
computer  hardware,  software,  and  scheduling  terminology. 

*  Establish  and  maintain  communication  between  users  and  automated 
scheduling  systems. 

*  Share  and  exchange  ideas  and  products  among  shipyards. 

*  Promote  trust  and  confidence  among  the  shipyard  users. 

*  Surface  scheduling  svstem  problems  and  provide  mutuallv  supportive 
resolutions.  [Ref.  FO] 

This  FASS  User's  group  was  initiated  to  develop  a  strategy  to  assist  each 
shipyard  in  obtaining  productive  status  with  the  FASS  system  in  the  shortest  possible 
time.  Two  of  the  main  ideas  of  the  group  were  the  establishment  of  a  core  database 
and  the  problems  concomitant  with  interfaces. 

The  core  database  was  to  serve  as  the  point  of  departure  for  standard  process 
and  reports  development.  An  input  by  the  user's  group  was  the  use  of  consistent 
conversions  of  database  elements  so  that  any  communication  between  the  individual 
shipyards  would  not  be  stymied  by  different  and  essentially  undecipherable  computer 
code.  It  was  established  that  the  contents  of  the  core  database  be  limited  to  those  data 
elements  used  by  the  majority  of  the  shipyards  with  built-in  capabilities  for  database 
expansion  when  FASS  capabilities  were  more  fully  realized. 

The  interface  problem  was  recognized  early  as  one  of  the  most  important 
capabilities  to  be  developed  between  FASS  and  the  shipyard  mainframe.  The  group 
decided  that  the  interface  be  accomplished  by  either  magnetic  tape  or  a 
communications  link  (27SO  37SO  protocol).  For  example;  Long  Beach  Naval  Shipyard 
uses  the  communications  protocol  as  the  interface  link  with  the  mainframe  while  the 
magnetic  tape  is  a  historical  record.  Long  Beach  also  has  the  communications  link  via 
modem  to  the  other  shipyard  FASS  systems  for  data  exchange.  At  the  present  time 
this  FASS  User's  Group  meets  twice  a  year  to  discuss  problems  relating  to  all  of  the 
shipyards.  The  accomplishments  of  the  first  three  FASS  User  s  Group  conclaves  have 
been  synopsised  below: 

*  A  common  core  database  has  been  developed  for  FASS  and  implemented  by 
all  shipyards  and  SEAADSA. 

*  Electronic  communication  procedures  and  transfer  of  software  routines 
between  shipyards  have  been  developed  and  implemented. 
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An  electronic  mail  week.lv  news  bulletin  was  implemented  and  shipvard 
procedures  for  use  of  the  bulletin  were  established. 

Procedures  for  eliminating  redundance  of  programming  bv  shipvards  and 
SEAADSA  have  been  established. 

*  Procedures  for  sharing  and  soliciting  better  business  practices  have  been 
established  and  utilized! 

Sharing  and  exchange  of  methodologies  and  products  between  the  shipvards 
has  been  enhanced  by  the  User's  Group. 

The  latest  meeting  held  in  September  1*186  dealt  with  the  growth  potential  of  the 
Code  3"5  branch  of  the  shipyard.  The  consensus  is  that  Code  375  rather  than  the 
shipyard  ADP  must  define  and  design  production  information  systems.  This  is  a 
radical  move  for  decentralization  in  the  shipyard  data  processing  organization.  At  this 
stage  of  implementation  the  User's  Group  is  fine  tuning  the  FASS  system  and 
developing  new  ways  for  the  ARTEMIS  software  to  produce  exactly  what  they  want  in 
the  way  of  graphics  and  reports.  The  FASS  User's  Group  is  concerned  with  two  main 
difficulties  that  may  impede  full  and  accurate  implementation:  ( 1 )  Cost  Schedule 
Control  System  (which  will  be  discussed  in  the  following  section)  and  (2)  the  Navy's 
competitive  bidding  policy  toward  overhaul  of  ships  and  submarines.  There  is 
tremendous  concern  among  all  the  FASS  users  that  conflicts  of  interest  may  arise  in 
the  shipyards  between  getting  the  bid  for  a  ship  overhaul  and  exchanging  information 
that  may  make  one  shipyard  more  efficient  than  another.  As  can  be  recalled,  one  of 
the  cornerstones  of  the  FASS  User's  Group  charter  was  the  sharing  and  exchanging  of 
ideas  to  make  all  the  shipyards  more  efficient  and  to  cause  shorter  overhauls  which 
would  save  taxpayer  money.  This  conflict  could  possibly  break  down  productive 
communications  between  the  shipyards  and  cause  damage  to  them  all.  A  strong 
solution  that  has  been  proposed  by  the  User's  Group  is  for  all  the  Navy  shipyards  to 
bid  as  a  corporation  rather  than  as  individual  entities.  This  would  at  one  stroke 
remove  any  secrecy  and  would  keep  the  ideas  and  exchanges  of  data  flowing  between 
the  shipyards. 

The  FASS  User's  Group  is  the  strongest  force  in  implementing  FASS  at  an  equal 
pace  in  the  shipyards.  The  exchange  of  data  is  helping  each  shipyard  to  be  more 
efficient  and  cost  productive.  The  value  of  the  User's  Group  is  the  main  reason  FASS 
i*.  becoming  as  powerful  a  tool  as  it  has  become. 
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D.  COST/SC H ED I'LE  CONTROL  SYSTEM 

The  Cost  Schedule  Control  System  (CSCS)  is  an  idea  that  private  industry  has 
used  for  years.  The  primary  reason  that  Naval  shipyards  have  adopted  this  system  is 
to  maintain  shipyards  in  a  required  state  for  wartime  readiness  and  still  meet  technical 
requirements  of  ship  overhauls  ahead  of  established  schedules  and  at  a  reasonable  cost, 
preferably  under  cost.  These  lofty  ambitions  are  striven  for  without  sacrificing  gains 
made  in  quality  and  scheduling.  The  system  is  designed  for  the  middle  managers  of  the 
shipyard,  the  general  foreman,  and  shop  foreman.  A  typical  shipyard  system  hierarchy 
is  shown  in  Figure  5.7.  [Ref.  1 1]  The  elements  of  a  CSCS  system  include: 

*  Discipline-bias  toward  improvement. 

*  Control  of  overhead  expenses. 

*  Work  organized  into  manageable  packages. 

*  A  plan  to  accomplish  each  package. 

*  A  measurement  of  costs  of  work  performed. 

*  A  measurement  of  the  physical  progress  of  work. 

*  Ability  to  detect  variances  from  the  plan  and  ability  to  take  corrective  action. 

[Refill) 

This  system  is  designed  to  reduce  costs  in  the  Navy  shipyards  by  adhering  to  the 
principles  stated  below  and  shown  in  Figure  5.8: 

*  System  based  on  integrity.  Actual  cost  data  and  actual  schedule  progress  data 
will  be  collected  for  producing  a  precise  report  of  actual  performance. 

*  The  highest  lev  el  of  the  cost  hierarchy  will  be  the  project  budget. 

*  Project  work  scope  will  be  broken  down  into  relatively  small  work  task 
elements  which  will  be  assigned  a  cost  estimate  and  a  performance  schedule 
which  will  be  the  structural  foundation  for  measuring  cost  and  schedule 
performance. 

*  Cost  performance  will  be  measured  by  comparing  actual  costs  for  work 
performed  to  planned  costs. 

*  Schedule  performance  will  be  measured  bv  comparing  actual  progress  to 
planned  progress  at  the  appropriate  levels. 

*  Deviation  of  actual  performance  from  planned  performance  will  be  resolved  by 
the  responsible  line  manager.  [Ref.  12) 

The  primary  reason  that  CSCS  is  mentioned  in  the  implementation  of  FASS  is 
that  even  though  the  full  power  of  FASS  is  not  yet  fully  understood  by  the  FASS 
users,  this  new  concept  is  being  added  to  already  burdened  staffs.  Three  of  the 
shipyards,  Fong  Beach.  Mare  Island,  and  Charleston,  have  arrived  at  three 
methodologies  for  CSCS  FASS  implementation.  Fong  Beach  plans  to  use  the  shipyard 
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mainframe  for  CSCS  "number  crunching"  and  down-loading  to  the  ARTEMIS 
software  for  graphic  representation  as  shown  in  Figure  5.9.  Mare  Island  plans  to 
interface  the  shipyard  mainframe  to  FASS  to  down-link  data  from  the  SYVI1S  and  use 
ARTEMIS  software  to  analyze,  and  to  produce  reports  and  graphics  for  CSCS. 
Charleston  is  using  the  Mare  Island  approach  with  the  exception  of  using  a  different 
software  package  with  ARTEMIS.  The  User's  Group  meeting  in  September  held  a 
separate  conclave  dealing  specifically  with  CSCS.  The  consensus  was  that  Long  Beach 
and  Charleston  provide  a  summary  of  their  systems  development  to  date  and  to 
identify  the  differences  between  the  systems.  The  group  also  felt  that  CSCS 
calculations  would  be  best  achieved  on  the  shipyard  mainframe  and  that  the  standard 
graphics  should  also  be  generated  on  the  mainframe  due  to  the  volume  and 
distribution  considerations  of  the  reports.  The  main  complaint  of  the  User's  Group 
concerning  CSCS  is  the  fact  that  FASS  is  being  utilized  for  implementing  CSCS  in  the 
shipyards.  This  is  not  what  FASS  was  designed  to  do.  FASS  is  first  and  foremost  a 
scheduling  tool  and  the  addition  of  a  non-scheduling  memory  sinking  concept  like 
CSCS  is  counter  productive  to  a  full  understanding  and  utilization  of  FASS. 
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Figure  5.9  Typical  ARTEMIS  Software  Management  Graphics. 


VI.  CURRENT  FASS  UTILIZATION 


A.  PUGET  SOUND 

Puget  Sound  Naval  Shipyard  has  fully  implemented  FASS  and  is  coping  with  the 
Cost  Scheduling  Control  System.  FASS  at  Puget  Sound  is  menu  oriented  and 
password  controlled.  There  is  a  nuclear  and  non-nuclear  master  schedule  built  into  the 
memory'  that  can  be  altered  with  any  special  overhaul  key  events,  milestones,  or  jobs 
that  may  be  particular  to  a  certain  type  of  ship  or  submarine.  The  system's  network 
for  the  Production  Planning  Branch  is  depicted  in  Figure  6.1.  Puget  Sound  has  the 
largest  inventory  of  remote  printers  and  plotters  of  all  the  shipyards.  Long  Beach 
Naval  Shipyard  is  in  the  process  of  shifting  some  of  that  procured  excess  to  their  FASS 
site  thereby  recognizing  an  early  cost  benefit  from  the  Navy's  overall  FASS  system. 
Puget  Sound  has  progressed  to  the  point  that  the  weekly  reports  endemic  to 
Production  Control  have  been  placed  on  permanent  disk  in  the  FASS  computer  room 
and  are  no  longer  a  part  of  the  shipyard  .VI  IS  produced  reports.  Puget  Sound  is  also 
utilizing  the  "What- If'  capability  of  FASS  allowing  them  to  take  advantage  of  the 
ability  of  the  schedulers,  foreman,  or  management  to  change  the  event  or  the  duration 
of  the  milestone  or  the  calender  resulting  in  a  new  event  report  incorporating  these 
changes  and  any  other  concomitant  changes  in  the  schedule. 

Puget  Sound  has  incorporated  the  Cost  Scheduling  Control  System  (CSCS) 
concept  into  their  system  and  the  shipyard  MIS.  They  have  recognized  the  value  of 
CSCS  to  the  shipyard  and  have  produced  their  own  training  manual.  This  manual 
shows  the  schedule  hierarchy  and  explains  the  CSCS  graphics  terms.  (Ref.  11]  As 
stated  in  chapter  five  the  shipyard  mainframe  must  still  do  the  massive  numerical 
manipulations  to  produce  the  schedule  and  cost  variances  while  the  FASS  graphics 
produces  the  final  printouts.  Puget  Sound  has  found  that  the  key  to  success  with 
CSCS  is  a  combination  of  the  following: 

*  Manageable  "packages"  of  work. 

*  A  plan  to  accomplish  each  package  of  work. 

*  A  stable  estimating  base. 

*  Manhour  "budget  "  for  each  package. 

*  Accountability. 

*  Accurate  labor  charging. 


PRODUCTION 

CONTROL 


PLANNING 

AND 

ESTIMATING 


SYMIS 
(NO  PS) 


PCS  I 

DATABASE 


REPORTS  4 
GRAPHICS' 


CSCS 

MANUAL  INPUT 


Figure  6.1  Puget  Sound  Production  Planning  Branch  Network. 

*  Surveillance  of  labor  charges,  phvsical  progress/completion,  and  specification 
adherence. 

*  Real-time  reaction  to  variances. 

*  Investigation/resolution. 

*  Discipline! 

Puget  Sound  has  organizationally  found  that  Code  379  has  control  of  the  FASS 
system  in  all  respects.  The  reasoning  behind  this  is  that  the  system  is  in  the  hands  of 
the  people  that  must  be  familiar  with  it  to  best  accomplish  their  jobs. 

B.  LONG  BEACH 

Long  Beach  Naval  Shipyard  has  implemented  their  FASS  system  as  depicted  in 
Figure  6.2.  This  has  allowed  the  mainframe  MIS  to  contain  the  massive  memory  and 
allows  FASS  to  remain  relatively  unencumbered  to  produce  their  scheduling  reports. 
Long  Beach  has  also  developed  their  own  set  of  CSCS  graphics  in  conjunction  with  the 
MIS.  Additionally,  Long  Beach  produces  the  automated  workload  and  resource  report 
(WARR)  that  is  turned  in  monthly  to  NAVSEA.  Long  Beach  has  also  produced  an 
automated  overtime  tracking  report  that  allows  for  an  audit  trail  when  required.  Long 


Beach  has  also  developed  an  automatic  update  of  any  overhaul  schedule  based  on  the 
real  time  progress  as  extracted  from  PCC-268  data. 
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Figure  6.2  Long  Beach  Production  Planning  Branch  Network. 

Long  Beach  has  developed  FASS  to  its  fullest  potential  by  pushing  the  system  as 
far  as  it  wall  go  then  modifying  it  to  go  further.  They  have  developed  resource 
scheduling  techniques  that  allow  maximum  utilization  of  the  workforce  and  already- 
reduced  the  overhaul  time  required  on  one  ship  by  believing  in  the  output  of  FASS. 
Long  Beach  has  gone  to  the  other  shipyards  and  is  in  the  process  of  building  a  master 
library  of  ship  overhaul  schedules  based  on  standard  work  breakdown  structures  which 
results  in  the  avoidance  of  redundant  work  by  their  own  schedulers.  This  aspect  shows 
great  promise  of  significantly  reducing  overhead  in  future  overhauls.  The  immediate 
advantage  of  having  such  a  library  is  the  time  reduction  that  occurs  in  responding  to 
contract  awards  in  the  competition  with  other  public  and  private  shipyards. 

Long  Beach  is  experiencing  a  slow  down  of  the  system  while  doing  large 
networks.  It  is  taking  as  much  as  24  hours  to  analyze  and  report  on  some  large 
networks.  The  apparent  source  of  this  slow  down  is  the  float  allocation  procedure  is 


proving  to  he  very  time  consuming.  What  this  points  out  is  the  (act  that  the 
minicomputer  which  is  the  heart  of  I  ASS  may  still  he  too  small  in  memorv  capauts  to 
handle  very  large  projects.  Long  Beach  feels  that  although  LASS  is  a  scheduling  tool 
that  has  unlimited  potential  in  theory  it  is  quite  limited  in  real  life  by  its  memory 
capacity.  Due  to  these  limitations  most  of  the  work  has  been  in  producing  reports  for 
schedulers  and  shop  foreman.  The  automated  overtime  and  CSCS  functions  have  been 
regulated  to  third  and  fourth  priorities. 

Other  than  nagging  mini  mainframe  interfacing  problems  the  only  major  casualty 
to  their  system  has  been  an  unreliable  CALCOMP  1077  plotter  which  is  now  repaired. 
The  information  gleaned  from  the  repair  of  this  plotter  in  relation  to  optimum  vacuum 
settings  and  the  squaring  of  the  reference  points  is  of  great  interest  to  the  other 
shipyards  that  are  experiencing  the  same  problems  with  their  own  1077  s. 

Long  Beach  has  implemented  CSCS  on  the  FASS  system  using  the  guidance 
provided  by  NAVSEA.  [Ref.  12]  Additionally.  Long  Beach  has  completed  CSCS 
reports  by  performing  keyop  audit  checks  on  time  cards. 

Organizationally  Long  Beach  subscribes  to  the  Code  379  approach  as  reflected  in 
Chapter  V.  This  approach  allows  the  three  people  who  are  intimately  familiar  with 
FASS  to  look  at  ways  of  improving  the  scheduling  aspects  and  the  report  formats  to 
the  schedulers  who  use  them.  This  removes  the  burden  of  R&D  from  the  Code  37S 
schedulers  and  allows  Code  379  to  constantly  improve  FASS  operations  and  outputs. 

C.  MARE  ISLAND 

Mare  Island,  along  with  Portsmouth  Naval  Shipyard  were  the  first  shipyards  that 
received  the  FASS  system.  The  software  they  started  with  was  ARTEMIS  5 WO. 
ARTEMIS  6000  is  now  in  place  at  all  eight  shipyards.  This  has  necessitated  some 
small  change-overs  in  procedure  for  Mare  Island.  They  have  a  nuclear  and  non¬ 
nuclear  scheduling  master  residing  on  their  FASS  mini.  Mare  Island  also  uses  basically 
the  same  networking  model  as  Puget  Sound  shown  in  Figure  6.3.  There  have  been 
small  problems  in  interfacing  with  the  mainframe  but  with  the  help  of  the  FASS  User's 
Group  they  have  been  solved  satisfactorily.  Mare  Island,  organizationally,  has  FASS 
in  the  Code  377  section  of  Production  Control.  In  all  other  respects  Mare  Island  most 
closely  resembles  Puget  Sound  in  its  current  FASS  utilizations. 


Pearl  Harbor  has  fully  implemented  FASS  into  its  Production  Control  branch. 
Additionally,  Pearl  has  implemented  an  excellent  CSCS  package  into  their  system. 
Their  CSCS  system  has  been  tried  on  a  ship  and  two  submarines.  Both  the  nuclear 
and  non-nuclear  schedules  have  been  exercised.  Pearl  Harbor  also  uses  basically  the 
same  network  model  as  Long  Beach  Figure  6.4.  The  shipyard  has  divided  the 
responsibility  between  Code  377  and  Code  379.  Code  377  schedules  the  work  and 
Code  379  is  packaging  the  work  to  support  the  individual  tests.  For  example,  work 
required  to  support  test  number  1  will  be  packaged  and  scheduled  separately  from  that 
work  which  would  support  test  number  2.  The  end  product  of  such  a  sequence  of  work 
packages  is  the  test  of  the  entire  package  as  a  key  event  or  milestone.  An  innovation 
that  Pearl  has  developed  in  Code  143  is  a  program  that  extracts  data  from  the  SYMIS 
onto  a  PC.  This  is  done  once  a  week  and  is  reviewed  by  the  individual  keyop  mangers. 
This  data  is  then  run  through  FASS  for  local  reports  only  and  overall  efficiency  is 
increasing.  This  innovation  is  in  its  infancy  but  is  already  showing  great  promise. 
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Figure  6.4  Pearl  Harbor  Production  Planning  Branch  Network. 


Pearl  Harbor  shares  the  same  misgivings  as  the  other  shipyards  regarding  CSCS. 
Pearl  Harbor  has  issued  a  fairly  extensive  instruction  detailing  the  system  in  effect. 
Included  in  this  instruction  are  formats  for  three  reports  that  could  be  valuable  for 
other  shipyards.  The  reports  are  synopsised  below: 

*  PSL-05A  =  MILESTONE-KEY  EVENT  SCHEDULING  INTERFACE 

1.  Combines  nuclear  and  non-nuclear  work  into  one  report  grouping  kevops 

to  the  milestone-kev  event  interface  showing  most  recent  status 
information. 

2.  Program  highlights  keyops  that  may  be  deficient. 

3.  Program  performs  automated  rescheduling  of  kevop  when  the  master 
milestone  is  revised. 

*  PSL-05B  =  CURRENT  MKE  AND  PRODUCTION  CONTROL 
SUMMARY 

1.  Summarizes  potential  problem  kevops  and  shows  any  increases  or 
decreases  from  previous  reports.  These  reports  are  issued  once  a  week  and 
are  a  tremendous  asset  for  the  kevop  managers  in  finding  early  problems 

Pearl  Harbor  has  developed  its  own  backup  procedure  to  reduce  the  possibility  of 

lost  work.  A  auto  backup  will  occur  whenever  a  user  logs  off  his  ID.  thus  users  do  not 

have  to  remember  to  backup  their  work  every  day.  The  only  drawback  to  this 


procedure  is  that  it  now  takes  from  20  seconds  to  three  minutes  to  complete  log  o IT. 
This  lost  time  though  not  important  now.  will  be  when  the  system  is  more  fully  loaded. 

E.  PHILADELPHIA 

Philadelphia  Naval  Shipyard  is  the  shipyard  that  uses  the  minicomputer  (PASS) 
as  an  interface  between  existing  shipyard  computers.  The  line  diagram  is  shown  in 
Figure  6.5.  In  fact.  FASS  is  a  front  end  user  of  PASS  to  the  mainframe.  CSCS  has 
not  been  implemented  at  Philadelphia  at  the  present  time.  There  are  over  200 
individual  jobs  required  in  making  it  fully  operational.  Code  226.1  and  Code  226.2 
personnel  have  the  new  system  90  percent  implemented.  Long  Beach's  PC  268 
program  has  greatly  aided  Philadelphia  in  coming  as  far  as  it  has  in  implementation  of 
CSCS.  In  other  respects.  Philadelphia  is  no  different  from  the  other  naval  shipyards. 
Files  are  down-loaded  from  the  Honeywell  mainframe  to  FASS  for  graphic  outputs. 
Code  226.2  is  moving  toward  developing  automatic  updates  based  on  costs. 
Philadelphia  has  a  large  SLEP  (Service  Life  Extension  Program)  in  effect  and  it 
produces  specialized  reports  for  those  overhauls  that  are  different  from  the  regular 
overhaul  reports  that  FASS  has  produced.  Philadelphia.  Long  Beach,  and  Mare  Island 
have  the  float  allocation  program  installed  in  their  FASS  system  where  the  other 
shipyards  do  not.  Philadelphia  feels  that  the  float  algorithm  is  not  strong  enough  to 
support  overhauls.  It  sometimes  takes  as  long  as  two  weeks  to  get  results  from  their 
resource  loading  programs.  Another  problem  has  been  the  inclusion  of  the  SLEP 
program  into  FASS.  It  seems  that  FASS  is  too  small  storage-wise  to  support  it.  SLEP 
takes  up  to  55  percent  of  all  FASS  memory  and  leaves  only  enough  room  to  carry  one 
FF  size  ship  in  the  remainder  of  its  memory.  This  necessitates  a  greater  than  normal 
use  of  the  shipyard  mainframe  for  the  scheduling  aspects  of  the  other  ships  in  overhaul. 
Philadelphia  has  a  good  working  FASS  system  and  the  PASS  minicomputer  has  proven 
to  remove  some  of  the  memory  and  time-lag  problems  that  affect  the  other  shipyards. 

F.  CHARLESTON 

Charleston  relies  heavily  on  the  mainframe.  The  line  diagram  is  shown  in  Figure 
6.6.  Graphics  are  done  on  the  shipyard  MIS  while  all  reports  are  generated  by  the 
MIS  and  down-loaded  to  FASS  for  presentation.  Charleston  seems  to  have  some 
capacity  storage  problems  that  the  other  shipyards  have  not  reported.  They  also  need 
a  second  in"  plotter  to  accomplish  the  graphics  that  are  required.  CSCS  has  proven 
to  be  impractical  for  FASS  at  Charleston  and  they  have  not  placed  as  high  a  priority 


Figure  6.5  Philadelphia  Production  Planning  Branch  Network. 

as  some  other  shipyards  have.  Organization-wise  Charleston  utilizes  the  normal 
shipyard  structure  where  Code  375  is  in  charge  of  FASS.  Charleston  seems  to  be 
progressing  well  with  their  utilization  of  FASS  in  the  way  it  was  designed:  For 
scheduling.  With  the  exception  of  the  storage  problems  cited  above,  Charleston  does 
not  seem  to  have  any  major  problems  with  FASS. 

G.  PORTSMOUTH 

Portsmouth  Naval  Shipyard,  along  with  Mare  Island,  was  the  first  to  acquire  and 
implement  FASS.  The  network  line  diagram  is  shown  in  Figure  6.7.  With  the  older 
ARTEMIS  5000  software  they  have  had  cross-over  problems  in  using  the  ARTEMIS 
6000  but  these  appear  to  have  been  overcome.  As  with  the  majority  of  naval  shipyards 
Portsmouth  has  a  nuclear  and  non-nuclear  master  schedule  residing  in  FASS. 
Graphics  are  done  on  FASS  as  well  as  the  reports  that  are  peculiar  to  production 
control.  Their  FASS  routines  are  not  menu  driven.  They  also  have  a  paucity  of 
storage  even  though  they  have  a  library  disk  such  as  the  one  Long  Beach  produced. 
Portsmouth  espouses  wholeheartedly  the  CSCS  concept  and  conducts  classes  on  the 


Figure  6.6  Charleston  Production  Planning  Branch  Network.. 

waterfront  for  added  emphasis.  Another  accomplishment  in  their  FASS  displays  is  that 
after  a  plot  has  been  completed  the  information  excess  is  deleted  thus  conserving  disk 
space.  Also  when  the  plot  is  updated  the  information  is  stored  in  the  SYMIS  rather 
than  FASS.  The  reports  that  Portsmouth  uses  are  the  same  as  the  other  shipyards. 
Portsmouth  does  not  have  the  float  allocation  application.  They  are  organized  with  a 
Code  379  to  take  advantage  of  that  section  of  production  control's  expertise  in 
developing  new  and  more  useful  reports  to  the  keyop  managers  and  other  top 
management  in  the  shipyard.  Code  379  tracks  all  of  FASS's  data  sets,  global  variables, 
and  fields.  They  have  not  experienced  any  problems  in  interfacing  via  modem  with  the 
other  shipyard  FASS  systems  and  only  minimal  communications  difficulty  interfacing 
with  the  shipyard  mainframe.  Portsmouth  is  the  shipyard  that  has  had  FASS  for  the 
longest  period  and  its  experience  is  in  demand  at  the  User's  Group  conferences. 

H.  NORFOLK 

Norfolk  Naval  Shipyard  is  the  largest  of  the  naval  shipyards.  The  line  diagram  is 
shown  in  Figure  6.8.  It  has  become  imperative  that  scheduling  and  cost  controls  be 
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Figure  6.7  Portsmouth  Production  Planning  Branch  Network. 

taken  in  hand  as  quickly  as  possible.  Norfolk  has  fully  implemented  FASS  and  CSCS 
with  good  results.  The  FASS  is  menu  driven  with  command  files  for  producing 
graphics  and  reports.  It  also  issues  bar  charts  and  PERT  networks  to  the  waterfront 
and  has  a  strong  teaching  cadre  for  CSCS.  All  ships  currently  in  overhaul  at  Norfolk 
are  on  ARTEMIS.  Norfolk  probably  makes  the  most  use  of  its  overhaul  library  disk 
based  on  the  pure  volume  of  ships  in  overhaul.  Norfolk  has  an  excellent 
communication  system  between  the  shipyard  and  the  waterfront  and  has  a  large 
number  of  remote  sites  for  a  more  real  time  look  at  all  jobs  being  accomplished  by  the 
shipyard.  Because  of  its  size  Norfolk  is  experiencing  some  problems  in  their  networks 
and  with  the  communication  protocols  with  the  mainframe.  They  use  the  27S0 
protocol  exclusively  at  this  point.  Norfolk  is  currently  unable  to  run  multiple  plotters 
at  9600  baud  where  the  other  shipyards  have  not  indicated  any  problem  in  that  area. 
The  organization  at  Norfolk  is  the  standard  organization  cited  in  Chapter  V.  with 
FASS  under  Code  377.  One  political  problem  that  is  surfacing  is  between  FASS  and 
the  ADP  personnel  that  run  the  mainframe.  The  people  that  run  the  mainframe  feel 
that  FASS  should  be  able  to  run  itself  and  discourage  use  of  the  mainframe  for  the 
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heavy  memory  work.  FASS  also  wants  to  access  the  PC  iiie  but  are  not  allowed  by  the 
shipyard  ADP  personnel.  Norfolk,  is  trying  to  resolve  these  problems  expeditiously 
because  FASS  cannot  run  as  a  stand  alone  system  and  deliver  the  reports  that  the 
keyop  managers  must  have  to  make  their  decisions.  These  reports  are  issued  once  a 
week  and  are  a  tremendous  asset  for  the  keyop  managers  in  finding  problems  early. 


VII.  CONCLUSIONS  /  RECOMMENDATIONS 


A.  CONCLUSIONS 

1.  FASS  USEFULNESS 

After  completion  of  the  interviews  and  documentation  reviews  associated  with 
system  specifications,  requirement  analysis,  official  correspondence,  personnel 
requirements,  background  and  plans  concerned  with  the  acquisition,  implementation 
and  utilization  of  FASS,  it  is  evident  that: 

*  Personnel  involved  at  all  levels  are  dedicated  to  obtaining  a  uniformlv  high 
quality  product  useable  by  all  shipyards. 

*  Personnel  requirements  are  interpreted  verv  differentlv  at  all  shipyards  and 
even  at  different  levels  in  each  shipyard,  ranging  from  impressive  to  minimal. 

*  Definition  of  what  FASS  is,  and  what  it  should  be  used  for,  varies  greatlv  in 
its  extent  yet  does  not  vary  in  what  it  is. 

*  FASS  is  meeting  all  requirements  and  specifications  as  determined  prior  to 
purchase:  however  use  of  the  system  has  shown  that  all  requirements  and 
specifications  were  not  defined  enough  to  meet  todays  requirements. 

*  The  selected  ARTEMIS  svstem  is  having  a  positive  impact  on  the  the 
shipyard  scheduling  process  and  overall  effectiveness. 

When  used  as  designed,  or  as  modified  to  meet  the  individual  shipyards 
requirements  FASS  will  continue  to  have  a  growing  impact  on  all  shipyards  both 
operationally  and  economically.  W'ith  continued  and  improved  communications 
between  all  shipyards,  NAVSEA,  and  SEAADSA,  FASS  will  continue  to  be  modified 
to  support  the  present  and  ever  changing  demands  placed  on  it  by  the  users. 

2.  NETWORKING 

A  key  concern  of  each  shipyard  continues  to  be  just  how  to,  and  to  what 
extent,  FASS  should  be  networked  with  the  existing  systems.  FASS  was  designed  as  a 
stand  alone  system  but  has  proven  to  be  more  fully  utilized  if  networked  with  the 
existing  shipyard  systems.  The  limited  memory  capacity  of  FASS  requires  it  to  use  the 
data  storage  capacity  which  resides  in  the  existing  shipyard  computer  systems  to  obtain 
maximum  efficiency.  This  requirement  must  be  met  by  the  required  data  stored  in  the 
SYMIS  being  passed  to  FASS  via  a  network  scheme  of  some  type  thus  allowing  FASS 
to  use  its  limited  memory  capacity  for  processing  vice  the  data  storage.  This 
requirement  could  be  met  by  manual  entry  of  data  as  it  is  required;  however,  this 
would  be  a  step  back  in  time  negating  one  of  the  major  qualities  of  FASS  that  being 
the  timeliness  of  FASS  provided  information  and  results. 


3.  ACCEPTANCE 

Shipyard  management  has  met  the  test  and  although  each  has  answered  it  in 
slightly  different  ways  all  have  passed  by  proving  that  I  ASS  is  now  and  will  be  the 
only  way  to  do  scheduling  in  the  shipyards.  Some  of  the  upper  management  have  used 
the  "JL’ST  DO  IT"  approach  while  others  have  been  more  diplomatic  in  their  approach 
but  the  end  result  has  been  the  same  as  all  levels  of  all  eight  shipyards  are  rapidly 
joining  or  are  already  on  board  that  PASS  is  the  only  way  to  go  now  and  in  the  future. 
With  each  modification  to  PASS,  management  will  again  have  to  face  the  acceptance 
problems  but  they  will  be  much  smaller  in  magnitude  and  should  be  much  easier  to 
meet. 

4.  GROWTH  POTENTIAL 

As  FASS  is  accepted  to  greater  levels  in  the  shipyards  it  will  face  an  ever 
increasing  problem  with  growth.  That  is;  as  the  managers,  supervisors,  and  users  more 
fully  comprehend  and  understand  the  systems  applications,  they  will  want  to  have  the 
system  do  more  and  more  things  for  them  in  their  own  way.  Many  different  reports 
and  graphs  can  be  generated  by  both  the  main  and  desktop  versions  making  it  very 
attractive  for  each  person  to  want  to  have  the  data  entered  or  presented  in  a  special 
way  for  his  specific  need.  This  type  of  usage  not  only  duplicates  information  storage 
requirements  but  also  increases  processing  time  taking  it  away  from  other  services  the 
system  was  initially  designed  for.  Growth  of  this  type  is  not  necessarily  wrong  but  is  a 
major  control  problem  as  more  personnel  become  familiar  with  the  system. 

5.  CONTROL 

As  reflected  in  the  previous  section  on  Growth,  a  frequent  problem  associated 
with  computer  systems  is  the  growth  of  its  usage  after  the  initial  learning  phase  is 
completed.  This  problem  requires  close  and  continued  attention  by  upper  level 
shipyard  management  and  is  a  primary  reason  for  the  formation  of  Code  379  as  a 
central  control  point  for  the  overseeing  and  regulation  of  the  usage  of  FASS. 
Continued  success  of  the  system  depends  on  employing  it  for  additional  applications; 
however,  these  applications  must  be  uniform  and  applicable  to  more  than  just  one  user 
of  the  system.  A  prime  example  of  this  is  the  introduction  of  CSCS  onto  the  system 
only  to  find  that  while  it  has  produced  good  results  it  has  overloaded  FASS  and 
decreased  its  usefulness  for  its  intended  purpose:  Scheduling.  This  does  not  suggest 
that  new  and  useful  modifications  cannot  be  made  to  FASS  but  that  the  introduction 
of  such  modifications  must  be  carefully  controlled  and  monitored.  This  control  is 
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being  done  by  local  FASS  managers  and  overall  by  SEAADSA  and  the  PASS  u^ers 
group, 

6.  PERSONNEL  MANNING  AND  UTILIZATION 

The  status  of  personnel  manning  at  all  eight  shipyards  in  the  area  of  FASS  is 
up  in  the  air  without  a  standard  policy  for  having  or  not  having  a  Code  379.  Each 
individual  shipyard  has  gone  its  own  way  in  establishing  just  what  its  manning  will  be 
and  what  it  will  be  called.  In  order  for  FASS  to  be  utilized  as  it  was  designed  to  do  a 
standard  policy  must  be  set  and  adhered  to  as  much  as  possible  considering  the 
differences  in  the  networking  methods  applied  by  each  shipyard. 

The  authorized  and  actual  manning  levels  are  summarized  below  in  Table  1. 

TABLE  1 

FASS  MANNING  LEVELS 


SHIPYARD 

AUTHORIZED 

ACTUAL 

CODE 

Pueet  Sound 

9 

5 

379 

Lone  Beach 

5 

3 

379 

Mare  Island 

t- 

379 

Pearl  Harbor 

T 

1 

375.1 

Philadelphia 

7 

*> 

L 

226 

Charleston 

6 

4 

377 

Portsmouth 

7 

7 

379 

Norfolk 

1 

1 

377.6 

T  he  request  produced  by  Portsmouth  Naval  Shipyard  is  a  start  in  the  right 
direction.  Without  a  common  code  with  a  common  experience  level  required  for  that 
code  it  will  continue  to  be  a  problem  for  the  shipyards  to  communicate  and  work  with 
each  other.  Despite  the  best  intentions  of  all  involved  a  GS-9  with  only  a  scheduling 
background  working  in  code  .377.9  cannot  accomplish  as  much  as  a  GS-12  with  both 
scheduling  and  computer  background  working  in  code  379  when  dealing  with  other 
code  379s  from  other  shipyards  or  when  dealing  with  the  contractors  involved. 

7.  COST/SCHEDULE  CONTROL  SYSTEM 

While  CSCS  is  a  very  important  and  valuable  requirement  for  operation  of  the 
shipyard  its  association  with  FASS  is  not  desirable.  After  close  review  of  the  Long 
Beach.  Mare  Island,  and  Charleston  initiatives  several  items  concerning  the 
development  of  a  standard  CSCS  automation  are  evident; 

*  Use  of  estimates  versus  allowances  or  the  combination  of  the  two  in 
performing  CSCS  calculations. 


*  Where  data  originates  and  how  it  becomes  part  of  the  Production  Control 
master  file  in  each  shipyard. 

*  Calculation  of  the  Budgeted  Cost  of  Work  Scheduled  (BCWSk  Three  curves 
are  being  used  or  planned  (Original  BCWS,  Current  BCWS,  and  Revised 
BCWS). 

*  Which  schedule  dates  are  being  used  (earlv  start  earlv  finish  or  allocated 
start  allocated  finish)  to  trace  work  and  what  is  the’  potential  effect  on 
schedule  variance? 

*  Schedule  variance  at  the  line  item  level  when  estimates  are  made  at  the  kev 
operation  level. 

*  Should  CSCS  calculations  take  place  on  the  mainframe,  minicomputer 
(FASS).  or  combination  of  the  two? 

*  Where  should  CSCS  graphics  be  produced,  how  should  they  be  distributed, 
and  how  many  copies  of  each? 

The  Cost,  Schedule  Control  System  is  still  in  the  developmental  stages  of  its 
use  in  Naval  shipyards  and  as  such  many  of  the  answers  are  not  yet  available.  A 
continuing  process  of  solicitation  of  requirements  and  the  follow  up  feedback  is 
necessary. 

8.  IN-HOUSE  REVIEW 

FASS  has  now  been  in  use  at  Portsmouth  and  Mare  Island  for  an  extended 
period  of  time  allowing  these  shipyards  to  conduct  an  in-house  review  of  the  systems 
effectiveness  and  use-ability.  The  other  shipyards  may  at  any  time  conduct  their  own 
in  house  review  but  must  take  into  account  the  time  period  the  system  has  been  in 
place  and  the  amount  of  exposure  to  the  total  shipyard  workforce  it  has  had.  This 
review  is  not  meant  to  be  a  one  time  event  and  must  be  an  ongoing  requirement  placed 
on  the  FASS  system  managers  by  the  shipyard  commanders  if  FASS  is  to  continue  to 
be  utilized  and  improve  as  it  has  demonstrated  it  has  the  capability  of  doing.  The 
areas  covered  by  the  review  may  vary  from  shipyard  to  shipyard  and  time  to  time  but 
the  major  areas  that  should  be  covered  are: 

*  Assessment  of  overall  performance  of  the  svstem.  Is  it  an  asset  or  has  it 
become  a  liability? 

*  Accessibility  and  response  time. 

*  Information  flow,  amount,  and  form. 

*  Program  effectiveness. 

*  Training  effectiveness. 

*  Are  there  confusing  or  unused  areas  of  the  system? 

*  Is  FASS  assisting  or  burdening  the  supervisors? 

*  Is  the  system  being  utilized  by  all  levels  and  areas  of  the  shipyard? 
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These  on  going  reviews  will  take  a  considerable  amount  of  time  but  are 
necessary  to  preclude  the  possibility  of  misuse  or  nonuse  of  the  system.  [Ref.  l.'J 

9.  NAVSEA  REVIEW 

In  that  each  shipyard  has  undertaken  an  individual  approach  to  FASS  and  its 
utilization  the  effectiveness  of  each  approach  must  be  evaluated  by  an  outside  source 
(in  this  case  NAVSEA).  Just  because  one  shipyard  is  having  great  success  with  one 
form  of  implementation  and  utilization  of  FASS  is  definitly  no  guarantee  that  the  other 
seven  shipyards  would  succeed  using  that  form.  The  major  factor  affecting  the  success 
or  failure  of  the  system  at  individual  shipyards  may  not  be  in  the  method  of 
implementation  and  utilization  but  instead  might  be  management  support,  training  or 
acceptance.  [Ref.  14]  These  factors  cannot  be  reviewed  by  internal  organizations  and 
must  be  approached  from  a  knowledgeable  but  disinterested  point  of  view. 

B.  RECOMMENDATIONS 

1  SHIPYARDS 

The  following  list  of  recommendations  apply  to  all  of  the  shipyards  or 
interactions  between  them: 

*  Establish  a  common  basis  for  utilizing  FASS  for  its  intended  purpose: 
Scheduling. 

*  Establish  a  common  dataset  definition  for  mandatory  fields  to  be  extracted 
from  the  ST  MIS  master  files  for  FASS  use. 

*  Report  results  and  findings  of  resource  leveling  efforts  on  FASS  for  use  bv  all 
shipyards. 

*  Promulgate  command  file  and  documentation  for  loading  shop  work  center 
information  as  network  resource  records. 

*  Review  float  allocation  for  use  and  optimization  by  all  shipyards. 

*  Promulgate  the  source  and  extent  of  CALCOMP  expertise  for  the  benefit  of 
all  shipyards. 

*  Review  TLR  updating  process  for  replacement  bv  FASS  applications,  in  the 
two  shipyards  that  are  still  using  PS(TLR). 

*  Promulgate  process  for  updating  network  based  on  actual  finish  dates  and 
physical  progress. 

*  Share  the  Puget  Sound  Naval  Shipvard  Event  Management  and  Lead 
Shop,  Key  Shop  instruction. 

*  Provide  a  network  for  checking  validation  files  (dummies,  loop)  prior  to  input 
to  SYMIS  or  other  systems. 

*  Develop  lists  of  scheduling  problems,  scheduling  methodologv  used,  tvpes  of 
schedules,  and  tvpes  of  reports  used  for  exchange  with  each  other  and 
discussion  at  following  FASS  users  group  meetings. 

*  Develop  lists  of  hardware  software  or  svstem  utilization  problems  for 
discussion  resolution  at  following  FASS  users  group  meetings. 


*  Exchange  samples  of  FASS  products  as  produced  at  individual  shipyards. 

*  Utilize  SEAADSA  as  a  central  design  agency  for  new  standard  applications. 

2.  SEAADSA 

SEAADSA  should  be  responsible  for  acquiring  providing  the  following  items: 

*  Development  of  new  standard  applications  as  required  by  the  shipyards. 

*  Timing  test  results  on  Metier  float  allocation  process  using  laree  sized  network 
data  to  evaluate  the  extent  of  the  slow-down  problem. 

*  Establish  communication  with  the  ARTEMIS  users  association  to  exchange 
routines  ol  possible  interest  to  Navy  or  other  FASS  users. 

3.  NAVSEA 

It  is  recommended  that  NAVSEA  do  the  following: 

*  Take  action  expeditiouslv  on  the  Portsmouth  Naval  Shipvard  request  for 
establishment  of  Code  379.  Consider  the  extensive  merits  of  establishing  a 
Code  379  at  all  shipyards  as  part  of  the  standard  shipyard  organization. 

*  Promulgate.,  in  writing,  the  NAVSEA  policv  for  FASS  information  and  data 
sharing  in  light  of  the 'requirement  for  competitive  bidding  between  shipyards. 

*  Establish  a  policv  for  integration  of  FASS  within  each  shipvard  information 
processing  system. 

*  Establish  policv  for  CSCS  calculations  to  be  achieved  on  the  SYVI1S. 
Graphic  products  should  also  be  generated  on  the  mainframe  due  to  volume 
and  distribution  considerations. 

*  Direct  the  formation  of  an  advisorv  group  to  the  CSCS  Implementation 
Review  Team  consisting  of  shipyard  personnel  who  are  being  tasked  to 
implement  the  automation  of  the  CSCS  tool  in  the  shipvards. 


V.\-NCv> 
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VIII.  FURTHER  RESEARCH  OPTIONS 


By  January  19S7  the  entire  shipyard  complex  should  be  capable  of  using 
ARTEMIS  version  6.1  as  their  main  scheduling  tool  as  well  as  for  Cost  Schedule 
Control.  The  different  implementation  approaches  along  with  the  varied  results  in 
networking  and  utilization  of  TASS  will  provide  an  excellent  opportunity  for  further 
research  on  (1)  How  the  shipyards  view  FASS,  (2)  How  the  shipyards  utilize  TASS, 
and  (3)  Lessons  learned  concerning  the  purchase  and  use  of  commercial  software 
altered  for  use  in  the  Naval  shipyards.  A  study  of  these  lessons  will  identify  actions 
required  for  success  which  in  turn  will  benefit  all  aspects  of  computer  use  in  the 
government  military  complex. 
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